It is known to provide microcontroller units (MCUs) with comprehensive debug capabilities to assist in the debug of end applications. Such debug capabilities may include run control and trace of core, read/write access to memories and registers, etc. Access to these debug capabilities is conventionally provided via dedicated debug interfaces, for example based on specialised standards such as IEEE 1149.1 JTAG (Joint Test Action Group) and/or IEEE-ISTO 5001 Nexus.
Such specialised interfaces are optimised for debug use and provide good debug functionality. Such interfaces may also be used for end applications where provision has been included to allow tool access to the required interface signals. This requirement for access to interface signals purely for debug use conflicts with pressure to minimise the number of signals made available at the MCU; the pressure to minimise the number of signals being due to the need to increase reliability, and to reduce cost and size. For applications where the MCU is potted in an epoxy compound, this problem of requiring access to interface signals for debug use is amplified since there is no easy way to access debug signals even if the electronic control unit that contains the MCU is opened.
In an attempt to avoid the need for additional signals to be made available purely for debug use, it is known to enable standard non-debug interfaces that are used for application traffic to also be used for debug use. For example, monitor type software may be run on one or more processing cores to support such debug use of standard non-debug interfaces. However, a problem with this approach is that it involves the use of processing and memory resources in order to run the monitor type software, which itself may affect the operation of an application that is being debugged. In addition, there is the possibility that the actual application fault that is to be debugged could itself cause the monitor code to stop executing correctly.